Hey @EItanya thanks for the review! 😄
Fully agree that locking down the default ServiceAccount RBAC ( #40 ) is important and complementary ( In fact, I might try to address this problem in a new PR if I have time).

This flag is intentionally solving a different part of the problem: it controls which tools are advertised to agents via MCP, so write-capable tools are removed from the tool list entirely and the LLM never sees them.

That distinction matters because many “write” operations don’t go through the Kubernetes API at all. A lot of the tools we have here ( like helm uninstall, istioctl install, and especially the shell tool) execute via CLI shelling, so ServiceAccount verb restrictions won’t prevent them.

Even within a single category the auth model can be inconsistent. For example, cilium uninstall wraps Helm and goes through the K8s API (so RBAC would catch it), but cilium config set / cilium policy talk directly to the Cilium agent API and bypass K8s RBAC entirely. The most reliable way to prevent these across the board is to not expose them to the agent in the first place.

So I see these as two layers of the same story:

• This PR (application layer): controls what the agent can see and attempt. It covers all tool categories, including non-K8s CLIs
• add readonly flag for RBAC -> verbs: ["get", "list", "watch"] #40 (RBAC layer): controls what the ServiceAccount can do at the K8s API level. Which is obviously a valuable safety net for K8s-specific operations 😄

While reviewing this I also noticed a gap in my PR: the shell tool in the utils provider wasn’t gated by --read-only. That’s the highest-risk tool since it can execute anything on PATH ( kubectl delete, helm uninstall, rm -rf /, etc.), bypassing all other filtering. I pushed a fix for that 💪